1. Field of the Invention
The present invention relates to an apparatus and a method for processing control packets transmitted/received between devices that support a spanning tree protocol (STP).
2. Description of the Related Art
A spanning tree protocol is specified in IEEE (Institute of Electrical and Electronic Engineers) 802.1D (media access control (MAC) bridge and is for producing a single spanning tree (loop-free tree) from an arbitrary bridged LAN topology. The function of an STP is extended by IEEE802.1s (Multiple Spanning Trees) and IEEE802.1w (rapid spanning tree protocol, RSTP) and is widely used in bridge networks.
A bridge network, which is a communication network comprising a plurality of bridge devices, was mainly used in local area networks (LAN) at the beginning. However, recently, its area in use has been extended to a carrier network, as called “Wide area Ethernet (registered trademark)”.
Therefore, in order to reduce the number of interruptions of the frame transfer service of network devices operated by an STP, the improvement of its reliability/serviceability is required. An STP is not only limited to pure bridge devices, but also sometimes installed in a variety of network devices, such as a router and the like.
An STP is a communication protocol for determining a bridge device that becomes a root in a bridge network, establishing a communication route in a tree shape from the bridge device and prohibiting data from being transferred on a link other than the tree. Since a route is uniquely determined between arbitrary bridge devices thus, the generation of a loop can be prevented.
The bridge device receives an Ethernet (registered trademark) frame, determines an appropriate destination port on the basis of the destination MAC address of the frame, and transfers the received frame. In order to determine a root bridge device and a communication route, a control packet called a “bridge protocol data unit (BPDU)” is transmitted/received between adjacent bridge devices.
When determining a communication route, a BPDU that stores the cost value of each communication route is sequentially transmitted from the root bridge device to a link destination bridge device. Then, a bridge device that has received BPDUs from a plurality of bridge devices compares the respective cost values of these BPDUs and designates a port that has received a BPDU with the minimum cost value as a communication port. In this case, the other ports are blocked to prevent a loop from being generated, and are designated as alternate ports to be used at the time of failure.
Generally, a BPDU is defined as a control frame used to exchange a variety of information among bridge devices. If a topology is stable in a normal state, this BPDU is periodically and regularly transmitted from the designated port in order to monitor link failures. Specifically, the transmitting interval of the BPDU is called a “hello time”, and its default value is set to two seconds.
FIG. 1A shows an example of BPDU transmission/reception in such a normal state. The network shown in FIG. 1A comprises bridge devices 11, 21, 31 and 41, of which the bridge device 11 is assigned to a root bridge device. In this case, the port 43 of the bridge device 41 opposing the designated port 33 of the bridge device 31 is blocked as an alternate port.
A BPDU is sequentially transferred from the designated ports 12 and 13 of the bridge device 11 to another adjacent bridge device in the directions of the arrows. A BPDU transmitted from the designated port 12 is received by the root port 22 of the bridge device 21, and a BPDU transmitted from the designated device 13 is received by the root port 32 of the bridge device 31. A BPDU transmitted from the designated port 23 of the bridge device 21 is received by the root port 42 of the bridge device 41.
FIG. 1B shows a configuration of the active topology of a bridge network by an STP. FIG. 1C is a sequence chart showing BPDU transmission/reception in the normal state of the active topology shown in FIG. 1B.
The network shown in FIG. 1B comprises terminals 51 and 63, and bridge devices 52 (Bridge #1), 56 (Bridge #2) and 59 (Bridge #3). The bridge device 52 is assigned to a root bridge device. The terminals 51 and 63 are connected to the port 53 (P1) of the bridge device 52 and the port 60 (P1) of the bridge device 59, respectively. In this case, the port 61 (P2) of the bridge device 59 opposing the designated port 55 (P3) of the bridge device 52 is blocked as an alternate port.
A BPDU is transferred from the designated ports 54 (P2) and 55 (P3) of the bridge device 52 to the root port 57 (P1) of the bridge device 56 and the port 61 (P2) of the bridge device 59. Furthermore, the BPDU is further transferred from the designated port 58 (P2) of the bridge device 56 to the toot port 62 (P3) of the bridge device 59.
In order to shorten a time needed to transmit a BPDU, a configuration in which the transmitting process is autonomously performed by hardware is also proposed (see, for example, Japanese Patent Application Laid-open No. 11-205368).
If in a port such as a root port receiving BPDUs and the like, a state where no BPDU is received for a specific time is detected, the bridge device recognizes that there is a failure in the opposing designated port or the designated port is disconnected, and starts to newly re-configure a topology.
The lifetime of BPDU receiving information is a max age value with a default value of 20 seconds according to the STP specification. However, the lifetime of RSTP receiving information, which can be obtained by improving the speed of a SPT, is set to three times the hello time value with a default time value of two seconds. Therefore, in an RSTP, if no BPDU is received for six seconds (at least three seconds) at its default, a topology starts to be re-configured so as to make communication available by another link.
During re-configuring a new topology, communication is not available on a network. For this reason, after re-configuring a topology, in order to make communication available by the new topology, the flush process of the filtering database (MAC table) in the bridge device is performed throughout the entire network. An MAC table stores the correspondence relationship between an MAC address and the port of a bridge device. In the flush process, the entries of ports that become unnecessary by the re-configuration of a topology are deleted from the MAC table of each bridge device. Therefore, in succeeding communication, no destination MAC address of a received frame often exists in the MAC table, and a lot of flooding in which a frame is transferred to all ports other than a receiving port is frequently caused.
This is described below with reference to FIGS. 1B and 1C. If no BPDU is received from the designated port 58 of the bridge device 56 in the root port 62 of the bridge device 59 for six seconds due to some failure, the bridge device 59 generates a new topology, and designates the port 61, which has been blocked for an alternate port, as a root port and blocks the port 62, which has been a root port, for an invalid port. Thus, the frame transmitting/receiving route 64 between the terminals 51 and 63 is switched over to a route from the designated port 55 of the bridge device 52 to the port 61 of the bridge device 59.
However, the above-mentioned BPDU transmitting/receiving method has the following problems.
Regular BPDU transmission/reception is a very effective means for monitoring link failures. However, a problem occurs if the BPDU transmission stops for a specific time (in the case of RSTP, three times the hello time cycle) immediately after a BPDU transmission with no failure, in such a case as a software program built in each port is graded up in a bridge device.
Even if a software program for controlling BPDU transmission and the like, is stopping, a data communication service often has to be continued without instantaneous interruptions by performing a process of establishing a data path by hardware. In other words, in this case, there is no need for topology re-configuration and the flush of an MAC table, and it is preferable not to execute them.
However, in the conventional bridge device, a new topology is unnecessarily re-configured although a data path is available the same as before, and before the re-configuration is completed, many data paths in the network are made unavailable.
Therefore, in order to grade up the software program of a device operated by STP without interrupting the frame transfer service, the download of the software program and its initialization must be completed within the above-mentioned specific period. Although this specific time varies depending on the parameter value of a protocol, it usually is six seconds and is at least three seconds. It is practically impossible to complete the download and initialization of a software program within this period.
As disclosed by the above-mentioned Japanese Patent Application Laid-open No. 11-205368, a pseudo-BPDU can be generated during updating a software program by using hardware used to autonomously perform the BPDU transmitting process. However, in order to add a new hardware function to all bridge devices in a network, enormous labor and cost are needed.
Alternatively, memory can be duplicated by providing a CPU (central processing unit) with two segments of execution memory. In this case, while in one memory system a software program is executed, in the other memory system another software program can be loaded down. Then, the execution memory can be instantaneously switched over using the completion of the download as a trigger. This enables the stoppage time of the CPU to be shortened without being influenced by the download time of the software program. However, in this case, its installation cost increases due to the duplication.
Although the initialization of the CPU after the download of a software program can also be conducted within three seconds, in this case installation cost remarkably increases.
Furthermore, after being initialized, a bridge device that supports an STP transitionally transmits a BPDU in which the bridge device itself is designated as a root bridge device. In this case, since the opposing device performs the process considering that the topology has been changed when receiving the BPDU, the device temporarily stops the frame transfer service.
This can be avoided by providing a redundancy function to inherit a variety of STP parameters such as a port role and a port state, which dynamically change. However, in this case, too, installation cost increases, which is a problem.